home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 5299 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.0 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: void main() and other atrocities!
  5. Date: 9 Feb 1996 12:02:02 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4fg97qINNnug@keats.ugrad.cs.ubc.ca>
  8. References: <4eduaj$1aq@grouper.Exis.Net> <9602021300.AA04359@dxmint.cern.ch> <4f2rahINNmud@keats.ugrad.cs.ubc.ca> <4f7ifv$8l4@airdmhor.gen.nz>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <4f7ifv$8l4@airdmhor.gen.nz>,
  12. Simon Hosie <gumboot@airdmhor.gen.nz> wrote:
  13. >Kazimir Kylheku:
  14. >> It's also atrocious that main() has to be treated as a special language
  15. >> construct, and that a call to exit() in main() (when it is the last statement)
  16. >> is to be identical to a return.
  17. >
  18. >  It's already a special case in that the program starts there.
  19. >
  20. >
  21. >> I did read the relevant section in the FAQ. It is merely concerned with the
  22. >> issue of eliminating compiler warnings stemming from calling exit() in main()
  23. >> despite a "void" declaration thereof. The issue that a void function may
  24. >> not be compatible with a call to an int function doesn't seem that significant,
  25. >> since nobody in their right mind would design a compiler that way.
  26. >
  27. >  How about an operating system?  Nah, they'd never make an operating system
  28. >that expected a return value from a program, would they?
  29.  
  30. This is irrelevant since a program is not a C language function (under many
  31. operating systems). Try writing an assembly language program under Linux which
  32. terminates with a RET instruction. It will fail (even if you take care to pop
  33. the (argc, argv, envp) arguments off the stack first). There is nowhere within
  34. the address space of the process where it would even be reasonable to point a
  35. return address.
  36.  
  37. The exit status (not "return value", as you call it) is explicitly passed back
  38. to the OS through the _exit system call trap, no other way. It has nothing to
  39. do with any particular programming language paradigm.
  40.  
  41. If you set up your executable (under this particular OS) so that the
  42. machine-language entry point goes directly to your main() (or some other
  43. function), you would not be able to let the function "fall off" or attempt to
  44. return a value. You would have to make an explicit call to _exit().
  45.  
  46. In this case, an appropriate declaration for main() would be to return "void".
  47. Doing so would not mean that you are not complying with the operating system's
  48. expectation to yield an exit status.
  49.  
  50. What you are saying is a bit of a non sequitur, really. Most compilers do
  51. generate code that _won't_ break if you call an int declared function that was
  52. void defined (though you can't always count on it). Hence, declaring a void
  53. main(), while it is a transgression, is not a very serious error. On the other
  54. hand, most operating systems do allow or require a program to give an exit
  55. status, so perhaps your comment might have been worded as "Nah, they'd never
  56. make an operating system that _doesn't_ expect an exit status, would they?"
  57. since this is the less probable hypothesis.
  58. -- 
  59.  
  60.